Firmware Integrity Check Using Silver Measurements

ABSTRACT

Measurements of a device&#39;s firmware are made regularly and compared with prior, derived measurements. Prior measurements are derived from a set of identical firmware measurements obtained from multiple devices having the same make, model and firmware version number. The firmware integrity status is reported on a data and device security console for a group of managed endpoints. Alerts about firmware changes, which may be potential attacks on the firmware, are given automatically.

TECHNICAL FIELD

The present disclosure relates to the protection of electronic devicesfrom firmware attacks, and in particular relates to automaticallyderiving benchmark measurements with which to compare firmwaremeasurements.

BACKGROUND

There are increasing attacks on the BIOS (Basic Input/Output System) inelectronic computing devices, such as the implanting of rootkits in theBIOS. If the BIOS on a PC (Personal Computer) endpoint is compromisedwith a rootkit, there is no convenient or automated way at any givenpoint of time to check its integrity and perform remediation.Nevertheless, one way to check integrity of the firmware is to compare ameasurement of it with a golden measurement obtained from themanufacturer, but this is not always possible or desirable. Firmwarechecking applications that use golden measurements must be updated withnew golden measurements at the same time that the firmware is updated,otherwise legitimate firmware changes will be unnecessarily and widelyreported as suspect. Golden measurements must be made in exactly thesame way as the firmware measurements that are compared with the goldenmeasurements. The National Institute of Standards and Technology (NIST)has published a conceptual draft relating to BIOS integrity, entitled“BIOS Integrity Measurement Guidelines” (Publication number 800-155).However, the extent of its implementation is unknown as of the time ofwriting.

SUMMARY

In order to recognize attacks on a device's firmware, measurements ofthe firmware are made regularly and compared with prior firmwaremeasurements and/or silver measurements. Silver measurements, which arereputation based measurements, are derived from a set of identicalfirmware measurements obtained from multiple devices having the samemake, model and firmware version number. The comparison of firmwaremeasurements enables additional reporting to users and ITadministrators, to alert them about firmware changes. The firmwareintegrity status may be reported, for example, on a data and devicesecurity console for a group of managed endpoints. Real-time alerts canbe sent to the IT administrators and end users when firmware updates aredetected on their endpoints. Alerts about firmware changes, which may bepotential attacks on the firmware, can be given automatically.

An advantage of the invention is that the integrity of the firmware of adevice can be checked without having to obtain a golden measurement fromthe manufacturer, or without manually or otherwise making a goldenmeasurement. The applications that perform the firmware checks do notneed to be manually or automatically updated with golden measurements.Instead, the invention detects changes across multiple devices andautomatically determines whether the changes are genuine or suspect.Another advantage is that firmware roll-backs can be detected andreported. The embodiments disclosed herein each provide one or more ofthe above advantages.

Disclosed herein is a method for protecting electronic devicescomprising: receiving, by a server from each of a first threshold numberof electronic devices, an identically performed firmware measurement,wherein said devices have an identical make, an identical model and afirmware with an identical version number; determining, by the server,that at least a second threshold number of the received firmwaremeasurements are identical; defining, by the server, one of saididentical firmware measurements to be a silver measurement; receiving,by a processor, from a further electronic device having the identicalmake, identical model and firmware with the identical version number, afurther identically performed firmware measurement; and comparing thefurther firmware measurement with the silver measurement.

Also disclosed herein is a system for protecting electronic devicescomprising a server; a processor in the server; and a non-transientcomputer readable memory in the server that stores instructions, which,when executed by the processor, cause the server to: receive from eachof a first threshold number of electronic devices, an identicallyperformed firmware measurement, wherein said devices have an identicalmake, an identical model and a firmware with an identical versionnumber; determine that at least a second threshold number of thereceived firmware measurements are identical; define one of saididentical firmware measurements to be a silver measurement; receive,from a further electronic device having the identical make, identicalmodel and identical firmware version, a further identically performedfirmware measurement; and compare the further firmware measurement withthe silver measurement.

Still further disclosed herein is a non-transient computer readablemedium that stores instructions, which, when executed by a processor,cause the processor to: receive from each of a first threshold number ofelectronic devices, an identically performed firmware measurement,wherein said devices have an identical make, an identical model and afirmware with an identical version number; determine that at least asecond threshold number of the received firmware measurements areidentical; define one of said identical firmware measurements to be asilver measurement; receive, from a further electronic device having theidentical make, identical model and identical firmware version, afurther identically performed firmware measurement; and compare thefurther firmware measurement with the silver measurement.

This summary is not an extensive overview intended to delineate thescope of the subject matter that is described and claimed herein. Thesummary presents aspects of the subject matter in a simplified form toprovide a basic understanding thereof, as a prelude to the detaileddescription that is presented below. Neither this summary, the drawingsnor the following detailed description purport to define or limit theinvention; the invention is defined only by the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of an overview of the process for checkingfirmware, according to an embodiment of the present invention.

FIG. 2 is a schematic diagram of a system for firmware integritychecking, according to an embodiment of the present invention.

FIG. 3 is a flowchart of a process for providing a device's firmwaredata to a server, carried out by a firmware integrity check applicationinstalled in the device, according to an embodiment of the presentinvention.

FIG. 4 is a flowchart of a process for checking the integrity of thefirmware of a device, carried out by a backend server of the systemaccording to an embodiment of the present invention.

FIG. 5 is a flowchart of a process for automatically deriving silvermeasurements, carried out by the server of the system according to anembodiment of the present invention.

DETAILED DESCRIPTION A. Terminology

Device: This is any electronic device or any computing device to beprotected, which includes non-volatile memory and a BIOS or itsequivalent device firmware stored in the non-volatile memory.Non-limiting examples of a device include a laptop, cell phone, personaldigital assistant, smart phone, memory stick, personal media device,gaming device, personal computer, tablet computer, electronic book,camera with a network interface, and netbook. Most devices protected bythe invention will be mobile devices, but static devices, such asdesktop computers, projectors, televisions, photocopiers and householdappliances may also be protected. Many other kinds of electronic devicesmay be included, such as hi-fi equipment, cameras, bicycles, cars,barbecues and toys, if they include non-volatile memory and a BIOS orequivalent device firmware. Devices are configured to communicate with aremote server, and they may initiate the communications and/or thecommunications may be initiated by the server. Communications may be viaWi-Fi, SMS, cellular data or satellite, for example, or may use anothercommunications protocol. While the invention is often explained inrelation to laptops, it is to be understood that it applies equally toother electronic and computing devices.

ACPI: Advanced Configuration and Power Interface, an industryspecification for the efficient handling of power consumption in desktopand mobile computers. ACPI specifies how a computer's basic input/outputsystem, operating system, and peripheral devices communicate with eachother regarding power usage. ACPI defines tables that provide theinterface between an ACPI-compliant operating system and systemfirmware. The tables allow for the description of system hardware in aplatform-independent manner, and are presented as either fixed-formatteddata structures or in AML (ACPI Machine Language).

API: Application Program Interface

BIOS: Basic Input/Output System. This performs a power-on self-test ofthe hardware during the booting process of an electronic device,initializes the hardware, and provides runtime services for operatingsystems and programs. BIOS is an example of device firmware.

CHIPSEC: A framework for analyzing the security of PC platformsincluding hardware, system firmware (BIOS/UEFI), and platformcomponents. It includes a security test suite, tools for accessingvarious low level interfaces, and forensic capabilities.

Computer readable medium: A computer memory or memories of one or moredifferent types, each capable of storing computer readable instructionsand/or computer readable data.

FIC: Firmware Integrity Check, a process of the present invention inwhich the current firmware measurement of a device is checked against aprior firmware measurement and/or a silver measurement.

Firmware: Programming instructions that provide control, monitoring anddata manipulation for electronic devices. Firmware is typically storedin non-volatile memory components such as ROM (Read-only Memory), EPROM(Electronically programmable ROM), or flash memory in the device.Firmware such as the ROM BIOS of a personal computer may contain onlyelementary basic functions of the computer and may provide services tohigher-level software. Changing the firmware of a device mayoccasionally be done during its lifetime, for example for updating thefirmware, fixing bugs or adding features. Firmware may employ settingsthat are stored within the firmware or elsewhere in the non-volatilememory in the device. When used herein, the term “firmware” means devicefirmware such as BIOS, UEFI or similar, unless specifically statedotherwise.

Golden Measurement: In assessing the firmware measurements of devices, ameasurement assessment authority (MAA) references a set ofcharacteristics. These characteristics come in two varieties: (1)endpoint attributes and measurements of BIOS code provided and vouchedfor, using certificates, by the Original Equipment Manufacturer (OEM),Value Added Reseller (VAR), or an Independent Software Vendor (ISV); and(2) measurements of configuration settings either gathered by theuser/administrator of the endpoint during initial provisioning of theendpoint or by the MAA. The assemblage of ideal measurementcharacteristics is referred to as a golden measurement.

Hash: A hash function is any function that can be used to map data ofarbitrary size to data of fixed size. The values returned by a hashfunction are called hash values, hash codes, digests, hash sums, orsimply hashes.

NIST: National Institute of Standards and Technology

NVRAM: Non-Volatile Random Access Memory

OEM: Original Equipment Manufacturer

OS: Operating System

PCR: Platform Configuration Register, a storage register that is used tohold a value that summarizes all the measurement results that werepresented to it and the order in which those values were presented toit. The PCR is hosted by the TPM (Trusted Platform Module). The PCR hastwo advantages: an indefinite number of results can be stored in asingle register, and no measurement results need to be discarded to makeroom for new measurement results.

Processor: This term may be used to refer to a single computer processoror multiple computer processors.

RAM: Random Access Memory

Roll-Back: The change of software or firmware present on a device fromits present version to an older version.

Rootkit: A collection of computer software programs, typicallymalicious, designed to enable unauthorized access to a computer or areasof its software that would not otherwise be allowed, and/or to mask itsexistence or the existence of other malicious software.

Silver measurement: A reference measurement of firmware that is derivedfrom multiple identical measurements of different copies of the samepiece of firmware present on different devices of the same make andmodel. A silver measurement covers firmware code (i.e. computer readableinstructions) but excludes firmware settings, since the latter can beintentionally changed.

SMM: System Management Mode, an operating mode of a device in which allnormal execution, including the operating system, is suspended andseparate, special software, which is usually part of the firmware or ahardware-assisted debugger, is executed with high privileges.

SPI: Serial Peripheral Interface

TCG: Trusted Computing Group, a group formed to implement trustedcomputing concepts across personal computers.

TCPA: Trusted Computing Platform Alliance, the former name of theTrusted Computing Group

TPM: Trusted Platform Module, a dedicated microcontroller designed tosecure hardware by integrating cryptographic keys into devices. The TPMhosts the above-mentioned PCRs. The TPM specification was written by theTCG.

UEFI: Unified Extensible Firmware Interface, a specification thatdefines a software interface between an operating system and platformfirmware. The UEFI is stored as firmware in non-volatile memory.

WMI: Windows Management Instrumentation

B. Overview

Referring to FIG. 1 , a brief overview of the process for checking theintegrity of firmware is shown. In step 2, hashes of newly updatedfirmware are obtained from multiple devices. In step 4, the hashes areanalyzed in order to derive a silver measurement of the newly updatedfirmware. In particular, when multiple devices of the same make, modeland firmware version have hashes that are the same, then the particularvalue of the hash is deemed to be a silver measurement of the particularmake, model and firmware version. In step 6, the firmware of furtherdevices is measured to provide hashes, each of which is compared to thesilver measurement corresponding to the device's particular make, modeland firmware version. If the comparison results in a match, then thosedevices with a match can be considered to have firmware that is notcompromised. The devices that do not have a match can be considered tohave their firmware compromised.

C. Exemplary Embodiment

A symbolic block diagram of an exemplary embodiment of the system 10 forchecking the firmware integrity of a device 20 is shown in FIG. 2 . Thedevice 20 typically includes a display 22, one or more processors 24 andnon-volatile memory 26, which may be split into two or more constituentmemories. The device 20 also includes further, volatile memory 28, suchas RAM. The device 20 may also include a hard disk drive (HDD) 29, solidstate drive or other long-term storage.

Present in the non-volatile memory 26 (e.g. NVRAM) of the device 20 isfirmware 30, which may be any type of device firmware such as BIOS, UEFIor firmware that performs comparable functions to BIOS or UEFI. Thefirmware 30 may be divided into multiple volumes, and includes both codeand data. Each volume may store data, code, or both data and code. Thenon-volatile memory 26 also includes an identification 36 of the device20, an information module 32 and a persistence module 34. Thepersistence module 34 is normally located inside the firmware 30. Thenon-volatile memory 26 may store several firmware images of differentkinds as well as other non-firmware data. The information in module 32saved in non-volatile memory 26 includes, for example, non-volatile BIOSsettings, such as overclock settings, persistence activation state,enable/disable Secure Boot, and many other static BIOS settings. Theinformation module 32 may not necessarily be a single or specificallydefined module, but may include a collection of unrelated registers orother data storage areas, for example, which are collectively referredto herein as an information module for convenience. Dynamic informationsuch as whether USB devices are attached to the device 20, is kept bythe BIOS in memory 28. Also, the log (TCPA table), along with other ACPItables, are produced dynamically by firmware 30 and also stored inmemory 28.

The FIC application 40 is maintained in the volatile memory 28 by the OSagent 41. The OS agent 41 does not itself include any applications, suchas the FIC application, but exists to maintain a communication link tothe server 60. The server 60 transfers the FIC application 40 and otherapplications as necessary to the device through the OS agent'scommunication channel with the server. The persistence module 34 ensuresthat the OS agent 41 is present in an uncompromised state in thevolatile memory 28 of the device 20, or elsewhere in the device. If theOS agent 41 is not present in the device 20 or is found to becompromised upon boot, the persistence module 34, which includes amini-agent embedded in it, restores the OS agent directly from flashmemory or any other storage within the device, without any internetconnection to the device. It is also possible, in other embodiments, forthe persistence module to reload the OS agent 41 across the internet, ifthe persistence module has internet connectivity.

The FIC application 40 is responsible for calculating a measurement ofthe firmware 30, which may be a hash 42. When FIC application 40performs its measurements, the persistence module 34 is measured alongwith the rest of the firmware 30 because the persistence module is partof the firmware. The FIC application 40 stores the hash 42 as a hash 42Ain the HDD 29 or equivalent storage using the OS's cryptographic API.The FIC application 40 can make use of functions of the operating system44 to read the contents of the non-volatile memory 26, to changesettings in it and to write data to it. Versions of the firmware 30 canbe read using OS interfaces such as WMI, or they can be discovered in amore direct way using the FIC application 40, and then stored in theinformation module 32. Firmware version numbers may include numericaldigits, letters and/or other characters or symbols.

After the device has booted, the FIC application 40 can periodicallymeasure the firmware 30 and compare the measurements with previouslystored results that have been stored in the HDD 29. The volatile memory28 may contain ACPI tables that contain a measurement log, which can beverified with TPM PCR registers. UEFI firmware may create the ACPItables. The log can be checked with prior logs and/or silvermeasurements. The UEFI firmware volumes can be copied from non-volatilememory 26 by the FIC application 40, parsed, and measured as a whole asopposed to the TPM-based method. Firmware volumes are located innon-volatile memory 26 and mapped at a specific location in CPU (centralprocessing unit) address space, so the FIC application 40 can, via an OSdevice driver, map and copy firmware volumes from non-volatile memoryaddress space into the main memory 28.

In the TPM-based method, an immutable BIOS boot block storesmeasurements in PCRs on the TPM. A PCR register in the TPM is combinedwith a nonce and signed by a TPM-resident key to create a report on theBIOS code present at boot time. The measurement as a whole can either bedone in conjunction with the TPM-based method or on its own if there isno TPM, or if the BIOS does not generate the TCPA table. This mayrequire a kernel driver to directly access the memory 26 and ACPI tablesin the information module 32. As ACPI tables can be accessed via an OSAPI, however, use of a kernel driver is not obligatory. In Linux™systems the ACPI tables are mapped in a virtual file system. A kerneldriver would be necessary in other situations, such as reading BIOS fromflash, reading SPI controller registers, etc. Other, known types ofmeasurement may also be used.

As a separate check, the FIC application 40 can periodically read thenon-volatile memory 26, which includes e.g. flash regions and controllerlock registers, in a way similar to that performed by the CHIPSECutility, and report/alert if any region of the flash is unlocked. Thisrequires a kernel driver to access the physical hardware registers.

The device 20 is connected via communications link 52 and the internet38 or other network to a server 60, which is connected to the internetvia link 62. Further devices 20A, 20B which are similar in function todevice 20, for which the firmware is to be monitored, are connected tothe server 60 via the internet 38 and links 58, 59 respectively. Theserver includes one or more processors 64, user interface 66 and one ormore memories 68. The memory 68 stores one or more programs 70 forinteracting with the devices 20, 20A, 20B and storing informationrelated to their firmware in database 72. In particular, the database 72includes data entries 74 that relate identifications of specific devices20, 20A, 20B to their firmware, for example using firmware hashes. Forexample, data entry 74 includes a copy 36A of the device identification36 stored in relation to a copy 42B of the hash 42 of the firmware 30.The database 72 also includes entries 76 that relate device makes,models and their firmware versions (M-M-F) to silver measurements (S #)of the corresponding firmware. A database 72 includes the type of theflash controller and flash part of the device so that the FICapplication 40 knows how to access the flash lock registers on differentplatforms. Over time, additional functionality can be added to thedatabase.

A web front-end 80, which is a further computing device, is connected tothe server 60 via communications link 82 and the internet 38. Alertsindicating a change in the firmware 30 of device 20 are presented aspopup messages 86 on the display 84 of the web front-end 80, which canalso trigger emails or other messages to IT administrators. The system10 can also alert the end user directly with a popup message 90 or lockthe display 22 of the device 20, depending on the particular policyselected.

D. FIC Application Process

Referring to FIG. 3 , a flowchart is shown of an exemplary processundertaken by the FIC application 40 in a device 20 in which thefirmware is BIOS. In step 100, the FIC application 40 is initialized,which is achieved by loading, installing and running it in the device20, under control of the persistence module 34.

In step 105, the FIC application 40 receives a policy from the backend,i.e. the server 60. The policy includes instructions for the FICapplication 40 as to which parts of the firmware 30 to measure, how tomeasure them and how often to measure them, etc. The server 60 sends thepolicy and commands to the device 20, and the device sends data to theserver. In some embodiments, the server informs the FIC application 40on the device 20 whether its measurements are OK or not. However, thisstatus information may be intentionally withheld from a compromiseddevice if it is desired that the server continue to monitor thecompromised device, while keeping a user of the device unaware that thestatus has been determined.

In step 110, the application 40 gathers, from the device, the device'sBIOS version, the date and time of its build, and its size. It alsocalculates a hash 42 of the firmware 30, or a different hash for eachvolume of the firmware. Optionally, it gathers the I/O ports toenable/disable SMM and other parameters including published ACPI,SMBIOS, and/or other standard interfaces.

If, in step 115, there is no information previously saved on the deviceby the FIC application (i.e. firmware version, firmware date, firmwaretime and/or firmware hash) with the policy relating to the specificdevice, then the application 40 proceeds to step 118. In step 118, thegathered information and hashes from step 110 are securely saved locallyand sent to the server 60 in step 120. When the FIC application 40 runsfor the first time it takes the baseline measurement, saves it securelyon the device 20, and sends to the server 60. When the FIC applicationnext runs, it can then compare a new measurement with the saved baselinemeasurement, and, if different, send the new measurement to the serverif instructed to do so by to the policy. Optionally, in step 121, thedevice may receive an acknowledgment from the server if the measurementis acceptable, for example if it corresponds to a silver measurement.Alternately, the optional message back from the server may be a commandto take a security action, if the measurement does not equal acorresponding silver measurement. The process then ends in step 122.

Referring back to step 115, if the specific device information (i.e.firmware version, firmware date, firmware time and/or firmware hash) hasbeen previously gathered from the device 20 under control of the policy,which informs the FIC application 40 where to get the device specificinformation, then the process moves to step 125. In step 125, the FICapplication 40 determines whether the BIOS has been updated. This isdone by comparing the current data obtained in step 110 with theprevious data stored earlier in step 118. For example, this is achievedby comparing the current BIOS version number with the prior BIOS versionnumber; the current BIOS build date with the prior BIOS build date;and/or the current BIOS size with the prior BIOS size. If the BIOS hasbeen updated, then, in step 140, the FIC application 40 generates analert and the new information is sent to the server in step 145, afterwhich the process ends in step 150. Optionally, the device may receivean acknowledgment from the server or a security instruction before theprocess ends. The alert is displayed as a popup or message 90 on thedisplay 22 of the device 20, e.g. “Your device firmware was upgradedfrom version x to y; if you did not authorize the upgrade, shutdown thecomputer and contact your administrator. Unauthorized firmware changemay be a sign of a hacker attack.”

If, in step 125, the FIC application 40 determines that the BIOS has notbeen updated, then the process moves to step 130, in which the FICapplication compares the current hashes with the prior hashes. If, instep 135, the BIOS has been changed, then, in step 140, the FICapplication generates an alert and the new information is sent to theserver in step 145, after which the process ends in step 150. Inconjunction with the alert, the process may lock the device or permitrestricted use only of it until the change in the BIOS has been verifiedto be legitimate. As above, the alert is displayed as a popup or message90 on the display 22 of the device 20. If, in step 135, the BIOS has notbeen changed, which is determined by the current hash being equal to theprior hash, then the process permits normal or continued and unhinderedoperation of the device in step 148, and then ends in step 150. Inanother embodiment, step 145 may be performed after step 148 even ifthere are no changes to the BIOS, i.e. the data would be sent again evenif it has not changed.

The process can be repeated on every boot of the device or periodically,randomly or from time to time, starting from step 105 in which theinformation is received from the server.

E. Server Process

Referring to FIG. 4 , in step 200, the FIC feature for the device 20 isenabled, for example by an administrator setting a flag in server 60that indicates that the feature should be present on the device. Whenthe OS agent 41 in device 20 communicates with the server 60, the serverreads the flag and instructs the OS agent to initialize the FICapplication 40.

In step 205, the server 60 receives the BIOS version, build date andtime, BIOS size and hashes of the firmware volumes from the FICapplication 40 for the first time. This is achieved as a result of theFIC application 40 performing step 120 of FIG. 3 .

In step 210, the server 60 stores the received information (i.e. BIOSversion, build date and time, BIOS size and hashes of the firmwarevolumes) in the database 72, in a record 74 that links it to anidentification 36 of the device.

In step 220, the server 60 receives updated information including thecurrent firmware measurement for the device, as a result of the FICapplication 40 performing step 145 of FIG. 3 . In step 225, the server60 generates an acknowledgment that indicates that information has beenreceived. In step 230, the server determines whether the BIOS firmwarehas been updated to a later version, for example by comparing thecurrently received firmware version number with a previously receivedfirmware version number from the same device. If it has, then, in step235, the server determines whether a silver measurement is available. Ifa silver measurement is available, then, in step 245, the serverperforms a silver measurement check. This is done by comparing thecurrent firmware measurement with the silver measurement and determiningwhether there is a difference between the two. If, in step 250, theresult of the check is OK, i.e. there is no difference between thecurrent firmware measurement and the silver measurement, then the newinformation and optionally the OK status are stored in record 74 in thedatabase 72, in step 240. The status indicates that at the date and timeof the check, the firmware 30 is OK. As well, a message may be sent backto the device to inform it that the update in its firmware is legitimateand that it may continue with its normal and unhindered operation. Ifthe result of the silver measurement check is not OK in step 250, asecurity violation alert is generated in step 270.

Returning to step 235, if a silver measurement is not yet available,then the new information is stored in step 240 in the database 72 asrecord 74, or as an addition to record 74.

Returning to step 230, if the server determines that the BIOS has notbeen updated to a later version, the server then determines, in step 260whether the BIOS has been rolled back to a prior version. The serveridentifies a roll-back of the BIOS by determining that the currentlyreceived firmware version number is earlier than the previously storedfirmware version number from the same device. If the firmware has beenrolled back, then, in step 270 the server generates a security violationalert. If the BIOS has not been rolled back to a prior version, then theserver determines, in step 265, whether the hashes of the firmwarevolumes have been changed. If they have been changed, then, in step 270,the server generates a security violation alert. If the hashes have notchanged, as would be the case if step 145 is performed following step148, the server determines whether a later BIOS version is available instep 290. If there is not a new BIOS available, the process ends at step280. If a new BIOS is available, i.e. the current firmware is out ofdate, then a notification is sent to the IT administrator and/or theuser of the device 20 in step 295, after which the process ends in step280. The server can also check whether it is aware of a newer version ofthe firmware 30, and, if so, sends an alert to the user that a BIOSupdate is available, and to the IT administrator that the device 20still uses an older BIOS.

After each security violation alert in step 270, the parameters thatcaused the alert are displayed on the user interface 66 of the serverand/or as a pop-up 86 or other message on a web front-end computer 80 instep 275. In some embodiments, alerts may also be communicated from theserver 60 to the device 20 for display on the display of the device, orto trigger a security response in the device such as a lock-down. Aftergeneration of a security violation alert in step 270, the server maysend a message to the device to instruct it to freeze, to delete datatherefrom, to transmit data to the server, to reduce its functionality,or to transmit its location such that it can be tracked. Other securitymeasures are also possible. Following this, the process ends in step280. The process is then repeated from step 220 as and when it receivesnew data from the device.

If the flag in the server 60 for the FIC feature is not set, then the OSagent 41 of the device 20 will either disable the FIC application 40 ifit is present in the device or refrain from enabling it if it is absentfrom the device.

When measuring the firmware, care should be taken to measure the coderather than the data, otherwise the measurements may become meaningless.However, it is conceivable that the measurements may include apermissible range of allowed data and/or settings if the measurementchecks can allow for it.

F. Silver Measurement Determination

Referring to FIG. 5 , an exemplary process for deriving a silvermeasurement is shown. In step 300, the FIC feature is enabled onmultiple devices having the same make, model and firmware version. Instep 305, the server receives the BIOS information for the multipledevices, including the build date, time and size, and hashes of thefirmware volumes. The hashes must all be calculated in the same way inorder to provide consistent results. In step 310, the server determineswhether the number of devices for which the BIOS information has beenreceived is above a first threshold number. If the number of devicesdoes not meet the first threshold, the server proceeds to wait, and thenlater receives BIOS information from more devices, by returning to step305.

As an example, the first threshold number of devices may be equal to 10.However, in other embodiments the first threshold may be different,configurable and/or adjustable, either manually or automatically, andthe actual value may be based on statistical data.

Once the first threshold has been reached, the server determines, instep 315, whether the number of devices that have identical informationis above another, second threshold (which may either be the same numberas the first threshold or a lower number). This second threshold may be9, for example, which, if the first threshold is 10, would indicate witha relatively high probability that these 9 devices are uncompromised.The 1 device out of the 10, which has different information, maylikewise be considered to be compromised with a relatively highprobability. If the number of devices with identical measurements is notequal to or above the second threshold, then the process reverts to step305 to receive BIOS information from more devices.

If, in step 315, the number of devices that report identical BIOSinformation is equal to or above the second threshold, then, in step320, the hash of the reported identical BIOS information is set as thesilver measurement for the specific make, model and firmware version ofthe device. In step 325, the silver measurement (S #) is stored in thedatabase 72 in a record 76 that links to the specific make, model andfirmware version (M-M-F) of the device. The process ends in step 335,and may be repeated for other makes, models and/or firmware versions ofdevices that are to have their firmware integrity checked.

The result is that the server can look at new firmware, analyze it, andautomatically determine whether it is genuine or suspect without havingto compare it with a pre-existing benchmark. Once the new firmware isdetermined to be genuine, it is defined as a silver measurement. Thesilver measurement can then be used as a benchmark for checking thefirmware of further devices.

G. Variations

Note that the information obtained in step 110 (FIG. 3 ) may simply be arepeat of existing information, but received at a later time or date,which would indicate that the firmware 30 has not changed. In someembodiments, the device itself may not detect the change in thefirmware, but leave the detection of change to the server 60 to perform.

Thresholds in the determination of the silver measurement may bedifferent depending on the identity of the devices that initiallycontact the server with an updated firmware version. Lower thresholdsmay be used if the measurements are coming from devices that are, orbecome, known to be less susceptible to firmware attacks than otherdevices. The thresholds may be different depending on make, model,number of identified firmware attacks, location of the devices, owner ofthe devices, configuration of the devices, etc. The thresholds may alsovary with time.

In a basic embodiment, the silver measurement may include a firmwareversion number and firmware date and time. An intermediate embodimentmay further include one or more of the actual firmware volumemeasurements. An advanced embodiment may ultimately completely satisfythe NIST guidelines referred to above. Another possible variation is toinclude measurements of the firmware settings and to discover whichcombinations are disallowed by the customers.

Functions described as being performed by one server may be dividedbetween separate servers, and functions described as being performed onmultiple servers may be combined on the same server. Intermediateservers may also be employed in the system.

Steps in the flowcharts may be performed in a different order to thatillustrated, or they may be combined where shown separately. Steps maybe omitted and others added, and steps from different flowcharts may beinterchanged, all without departing from the scope of the invention.Components shown herein may be divided into constituent components or becombined with each other.

While the invention has been described predominantly with respect toBIOS, it applies equally to UEFI and other types of firmware.

In other embodiments, the persistence module is a form of firmware, butnot considered to be device firmware.

In general, unless otherwise indicated, singular elements may be in theplural and vice versa with no loss of generality. Drawings are not toscale or in proportion.

The detailed descriptions within are presented largely in terms ofmethods or processes, symbolic representations of operations,functionalities and features of the invention. These method descriptionsand representations are the means used by those skilled in the art tomost effectively convey the substance of their work to others skilled inthe art. A software implemented method or process is here, andgenerally, conceived to be a self-consistent sequence of steps leadingto a desired result. These steps involve physical manipulations ofphysical quantities. Often, but not necessarily, these quantities takethe form of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It will befurther appreciated that the line between hardware, software andfirmware is not always sharp, it being understood by those skilled inthe art that software implemented processes may be embodied in hardware,firmware, or software, in the form of coded instructions such as inmicrocode and/or in stored programming instructions. Computer readablememory or media described herein are all non-transitory in that theystore computer readable instructions and/or computer readable dataeither permanently or temporarily. A medium that can only support apropagating signal without storing it is considered to be transitory.

The present description includes the best presently contemplated mode ofcarrying out the subject matter disclosed and claimed herein. Thedescription is made for the purpose of illustrating the generalprinciples of the subject matter and not be taken in a limiting sense;the subject matter can find utility in a variety of implementationswithout departing from the scope of the disclosure made, as will beapparent to those of skill in the art from an understanding of theprinciples that underlie the subject matter.

1. A method for protecting electronic devices comprising: receiving, bya processor, an identically-performed firmware measurement from each ofa first threshold number electronic devices that have an identical make,model and firmware version number; determining, by the processor, that asecond threshold number of said firmware measurements are identical;defining, by the processor, a silver measurement to be one of saididentical firmware measurements; receiving, by the processor, a furtheridentically-performed firmware measurement from each of furtherelectronic devices that have the identical make, model and firmwareversion number; for those of the further electronic devices providingfirmware measurements that equal the silver measurement, the processorpermitting unhindered use thereof; and for those of the furtherelectronic devices providing firmware measurements that do not equal thesilver measurement, the processor taking a security action therefor. 2.The method of claim 1, wherein the security action is a restriction ofuse.
 3. The method of claim 1 further comprising, for one of the furtherelectronic devices providing firmware measurements that equal the silvermeasurement: determining, by the processor, that it has firmware that isout of date.
 4. The method of claim 1, further comprising: receiving, bythe processor, a different firmware version number from anotherelectronic device that has the identical make and model; determining, bythe processor, that the different firmware version number is earlierthan the identical version number; and generating, by the processor, asecurity alert indicating that a firmware of the other electronic devicehas been rolled back.
 5. The method of claim 1 further comprising, forone of the further electronic devices providing firmware measurementsthat do not equal the silver measurement: determining, by the processor,that a non-volatile memory in which firmware of said one furtherelectronic device is stored is not properly locked.
 6. The method ofclaim 1, wherein the firmware measurements are based on either: one ormore volumes of firmware; the firmware version number and a date of thefirmware; or a time of the firmware.
 7. The method of claim 1, whereinthe firmware measurements are of either: a BIOS (Basic Input/OutputSystem), or a UEFI (Unified Extensible Firmware Interface).
 8. Themethod of claim 1, further comprising storing, by the processor, allsaid firmware measurements in a database.
 9. The method of claim 1,wherein the first threshold number is equal to the second thresholdnumber.
 10. The method of claim 1, wherein the first threshold number isgreater than the second threshold number, the method further comprising:permitting, by the processor, continued unhindered use of those of theelectronic devices that have a firmware measurement equal to the silvermeasurement; and taking, by the processor, another security action, withrespect to those of the electronic devices that have a firmwaremeasurement different from the silver measurement.
 11. The method ofclaim 1, wherein each of all said firmware measurements is performed byan application running in volatile memory in either one of theelectronic devices or one of the further electronic devices.
 12. Themethod of claim 11, wherein each application is maintained to be presentand functional by an operating system agent running under an operatingsystem of the respective electronic device or further electronic device.13. The method of claim 12, wherein each operating system agent ismaintained to be present and functional by a persistent agent present innon-volatile memory of the respective electronic device or furtherelectronic device.
 14. The method of claim 1, wherein all said firmwaremeasurements are hashes of firmware instructions and not of firmwaredata or firmware settings.
 15. A system for protecting electronicdevices comprising: a server; a processor in the server; and anon-transient computer readable memory in the server that storesinstructions, which, when executed by the processor, cause the serverto: receive an identically-performed firmware measurement from each of afirst threshold number electronic devices that have an identical make,model and firmware version number; determine that a second thresholdnumber of said firmware measurements are identical; define a silvermeasurement to be one of said identical firmware measurements; receive afurther identically-performed firmware measurement from each of furtherelectronic devices that have the identical make, model and firmwareversion number; for those of the further electronic devices providingfirmware measurements that equal the silver measurement, permitunhindered use thereof; and for those of the further electronic devicesproviding firmware measurements that do not equal the silvermeasurement, take a security action therefor.
 16. The system of claim15, further comprising in each of the electronic devices and each of thefurther electronic devices: a firmware measurement application runningin volatile memory; an operating system agent running under an operatingsystem and configured to maintain the firmware measurement applicationpresent and functional; and a persistent agent in non-volatile memoryconfigured to maintain the operating system agent present andfunctional.
 17. The system of claim 15, wherein all said firmwaremeasurements are hashes of firmware instructions and not of firmwaredata or firmware settings.
 18. A non-transient computer-readable mediumthat stores instructions, which, when executed by a processor, cause theprocessor to receive an identically-performed firmware measurement fromeach of a first threshold number electronic devices that have anidentical make, model and firmware version number; determine that asecond threshold number of said firmware measurements are identical;define a silver measurement to be one of said identical firmwaremeasurements; receive a further identically-performed firmwaremeasurement from each of further electronic devices that have theidentical make, model and firmware version number; for those of thefurther electronic devices providing firmware measurements that equalthe silver measurement, permit unhindered use thereof; and for those ofthe further electronic devices providing firmware measurements that donot equal the silver measurement, take a security action therefor. 19.The non-transient computer-readable medium of claim 18, wherein all saidfirmware measurements are hashes of firmware instructions and not offirmware data or firmware settings.